In wirelessly providing (over a radio access network component of a cellular communication system, also having a core network for connecting to other networks) a multimedia (MM) stream from a streaming server to a streaming client wireless terminal, the communication path between the two may include a path link (segment of the path) that is a bottleneck, usually the path link connecting the radio access network to the wireless terminal streaming client. For example, as shown in FIG. 1, when a video stream from the Internet is to be wirelessly transmitted from a streaming server 11 to a wireless terminal streaming client 15, such as a mobile terminal, various path links are involved, including a core network (path link) 12, and a radio access network (path link) 14, which itself includes elements coupling directly to the core network 12 (i.e. elements on the core network side of the radio access network 14), and also elements on the air interface side of the radio access network, elements that provide the radio link 14-2, a segment (path link) of the overall communication path from the server 11 to the client 15 that generally offers more limited bandwidth than the other path links connecting the server to the client, and so is referred to here as a bottleneck path link. According to the prior art, for the communication path of FIG. 1 including the bottleneck path link 14-2, the multimedia stream is buffered and shaped at a packet scheduler node 13, i.e. the node immediately preceding the bottleneck path link 14-2 in the path leading from the server 11 to the client 15. (In the CDMA-2000 cellular communication system, the packet scheduler would be the base station controller; in UTRAN, it would typically be the radio network controller, or possibly a so-called Node B.) The packet scheduler 13 delays and drops transport packets when necessary in order to fit the stream into the limited bandwidth of the bottleneck path link 14-2, using a scheduling algorithm that provides different levels of service to different priority packets in the input buffer used by the packet scheduler 13.
The amount being held in the buffer of the packet scheduler 13 indicates how well the streaming server is adapting its transmission rate to the bottleneck path link 14-2, and therefore there is in the prior art, as indicated in FIG. 2, a method for measuring the amount being held in the buffer. The measurement is made based on the client (wireless terminal) 15, in response to receiving from the server (11), as a normal priority communication, a sender report indicating the last packet sent, sending a receiver report back to the server (11), usually at regularly scheduled intervals or even in some cases in response to each sender report, the receiver report indicating the last packet it has received (as of some time tr). When the server 11 receives the receiver report (at some later time ts), it computes the number of bytes en route to the terminal (and so not yet received) since it knows the last packet it sent to the client 15 (as of ts), and it provides further packets at a rate that accounts for the buffer size according to its calculation. However, as computed, the number of bytes also includes packets sent during the delay that it takes for the RTCP receiver report to arrive at the server, and is therefore somewhat inaccurate, and, moreover, even though the delay can be estimated via RTCP (real-time control protocol) reports (using a round-trip delay measurement), it can fluctuate. Another factor that influences the accuracy with which the server is able to monitor the bytes in the buffer of the packet scheduler 14-1 is the frequency of the RTCP reports; the more frequent the RTCP reports are sent by the client, the better the reaction-time of the server. But communicating the receiver reports imposes additional load on the radio access network uplink channel 14.
The patent application WO9900984 describes a method where the state of the buffer (indicating the size of its contents) and network congestion is evaluated using the receiver reports from the terminal.
What is needed is a way to provide good end-to-end quality of service for a streaming application, while addressing the prior art inaccuracies of the buffer content size calculations and the uplink load imposed on the radio access network.